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System and Method of 
Account Reconciliation- for Electronic Transactions 

Cross Reference to Related Patent Applications 

[0001] The present patent application is related to 
copending U.S. Patent Application , 



Attorney Docket No. 670744.00002, entitled "Method of 
Scheduling and Event Processing in Computer Operating System" 

10 and filed concurrently herewith by W. Jeffrey Knowles et al . 

The present patent application is further related to copending 

U.S. Patent Application , Attorney Docket 

No. 670744.00003, entitled "System and Method of Electronic 
Data Transaction Processing" and filed concurrently herewith by 

15 W. Jeffery Knowles et al. The present patent application is 

further related to copending U.S. Patent Application 

, Attorney Docket No. 670744.00004, 



entitled "System and Method of Currency Conversion in Financial 
Transaction Process" and filed concurrently herewith by W. 
20 Jeffrey Knowles et al. The present patent application is 

further related to copending U.S. Patent Application 

, Attorney Docket No. 670744.00006, 



entitled "System and Method of Transferring Data Through 
Transaction Process" and filed concurrently herewith by W. 
25 Jeffrey Knowles et al. 

Field of the Invention 

[0002] The present invention relates, in general, to data 
30 transaction processing and, more particularly, to system and 

method of account reconciliation for electronic data 
■transactions . 

Background of the Invention 
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[0003] An integral part of many financial transactions 
involves purchase of goods and services by credit card or other 
electronic transfer of funds. Consumers use credit cards to 
5 purchase goods and services from merchants and service 

providers. Businesses and government agencies use electronic 
fund transfers to acquire goods and services and issue credit 
cards to employees as necessary to conduct business. Credit 
cards are a convenient, safe, effective, and integral part of 

10 the economy. 

[0004] There are typically three financial institutions 
involved in credit card transactions: card association, issuing 
bank, and acquiring bank. Well known card associations operate 
under the names of Visa and MasterCard. The issuing bank 

15 issues a credit card to a cardholder. The credit card will 

include a credit line that will impose certain limits on the 
cardholder's ability to make purchases. The cardholder agrees 
to pay the amount due on the credit card statement, or minimum 
portion thereof with interest on the balance, to the issuing 

20 bank. The merchant has an account or relationship with the 

acquiring bank to initiate credit card transactions and 
ultimately receive payment for the transaction. The card 
association operates between the acquiring bank and issuing 
bank to coordinate and simplify the large number of 

25 transactions occurring on a daily basis. 

[0005] A credit card transaction usually starts at the point 
of sale where the cardholder has selected merchandise or 
service which he or she wishes to purchase. The merchant or 
service provider enters the credit card number by swiping the 

30 card through a terminal to read information stored on the 

magnetic strip or enters the credit card number directly into 
the terminal keypad. The terminal is connected to a 
communication network which electronically links the merchant 
to the acquiring bank or processing center. The acquiring bank 
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is electronically linked to the card association and the card 
association is electronically linked to the issuing bank. 
[0006] Most credit card transactions involve a two-part 
process. In the first part, while the cardholder is 
5 interacting with the merchant at the point of sale, a purchase 

authorization request is forwarded via an electronic 
communication network through the acquiring bank and card 
association to the issuing bank. The purchase authorization 
includes the merchant identification, amount of the purchase, 

10 and cardholder information. The cardholder information may 

include name, address, primary account number, PIN number, 
fraud protection data, etc. The purchase authorization checks 
with the issuing bank to see that the cardholder is in good- 
standing with the bank, that the purchase is within his or her 

15 approved credit limit, and that there are no other 

irregularities. The issuing bank approves the transaction for 
the requested amount and routes the approval back through the 
card association and acquiring bank to the merchant. Even 
though no money changes hands, the cardholder and merchant 

20 complete their interaction. The cardholder leaves the store 

with the merchandise in hand and the merchant receives 
assurance that the money will be paid. 

[0007] In the second part of the process, an aggregation of 
the individual purchase authorizations is processed through the 

25 credit card system to fund authorized transactions in a process 

known as clearing and settlement. During clearing and 
settlement, monies are scheduled to be transferred between 
accounts to complete specific pre-approved transactions. 
Transferring money, sometimes in different currencies, can be a 

30 time consuming, expensive, and error prone process. The 

aggregation of purchases and payment of net proceeds to the 
parties' during clearing and settlement is a more efficient and 
cost effective alternative to exchanging money during each 
transaction. Clearing and settlement may occur at the end of 
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the day, or at regular intervals during the day, or every few 
days depending on the volume of transactions and needs of the 
parties. However, the acquiring and issuing banks often do not 
have the resolution of the individual transactions to resolve 
5 discrepancies when reconciling the aggregation of transactions. 

If unable to balance the clearing and settlement, the banks are 
often forced to absorb the discrepancies based on the 
allocation of risk and may end up loosing money on certain 
transactions as part of the cost of doing business. 

10 [0008] A principal function of the card association is to 

act as a funding clearing house for the clearing and settlement 
process. An issuing bank may need to pay monies to a large 
number of acquiring banks and an acquiring bank may expect to 
receiving monies from a large number of issuing banks. By 

15 operating through the card association, the issuing bank makes 

one wire transfer to the card association to make payments to 
specific acquiring banks. Likewise, the acquiring bank 
receives one wire transfer from the card association to settle 
transactions for specific issuing banks. The card association 

20 receives funds and allocates funds to its individual members in 

order to clear and settle pending and approved credit card 
transactions . 

[0009] If the acquiring bank and issuing bank are based in 

different countries and operate with different native 

25 currencies, then the transfer of funds often requires one or 

more currency conversions. The acquiring bank generally leaves 
the currency conversions to the card association but in doing 
so the acquiring bank looses control and any benefit the 
conversion might yield to itself and to its customer, the ■ 

30 merchant. In the present competitive marketplace, giving up 

control of currency conversions involved in credit card 
transactions can be harmful to one's market share and profit 
margins. The customers of the acquiring bank (merchants) will 
demand the best rates and service or they will switch to 
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someone who can deliver. 

[00010] In actual business practice, there can be variations 
and exceptions to the above described process. For example, 
the acquiring bank and the issuing bank may be one in the same 
5 and card association may be left out of the transaction 

processes. Moreover, the acquiring bank and issuing bank often 
contract out one or more of the above support functions to 
third party processors or service providers. The processors 
operate and function on behalf of the bank to complete the 
10 transaction for the merchant and cardholder. The third party 

processors bring hardware and software expertise that can help 
the acquiring bank and issuing bank operate more efficiently, 
with lower costs,, and fewer errors. 

[00011] Accuracy in the transaction is an important aspect 
15 and consideration for both parties, as well as the financial 

institutions and third party service providers involved in 
processing the transactions. The merchant wants to receive the 
correct amount of money. The cardholder wants to be properly 
charged for the goods or services purchased. The acquiring 
20 bank, issuing bank, card association, and third party service 

providers each have vested interests in accurate transactions 
for the reputation and integrity of the system and to ensure 
that each receives the proper fees. While the card association 
issues reports or statements with respect to the clearing and 
25 settlement of transaction, there is no convenient or efficient 

way of independently verifying or confirming the accuracy of 
the card association statement. 



30 



Brief Description of the Drawings 

[00012] FIG. 1 is a block diagram of an electronic data 
transaction processing system; 

FIG. 2 is a block diagram of the transaction 
processing center of FIG. 1; 
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FIG. 3 is a block diagram illustrating the operation 
of the transaction processing center; 

FIG. 4 is a block diagram illustrating the data 
processing with the incoming queue and outgoing queue; 
5 FIG. 5 is a flowchart of the operation of data 

processing function in FIG. 4; 

FIG. 6 is a block diagram of the plurality of 
currencies used by the transaction processing center; 

FIG. 7 is a flowchart of the operation of the 
10 currency conversions of FIG. 6; 

FIG. 8 is a block diagram of the scheduler and event 
processor for the transaction processing center; 

FIG. 9 is a flowchart of the operation of the 
scheduler and event processor; 
15 FIG. 10 is a block diagram of an account 

reconciliation processor; and 

FIG. 11 is a flowchart of the operation of the 
account reconciliation processor. 

20" Detailed Description of the Drawings 

[00013] A transaction processing system 10 is shown in FIG. 
1. Transaction processing system 10 is applicable to many 
types of electronic transactions, including financial, 

25 reservations, and any other transaction involving the transfer 

of data. In the present discussion, transaction processing 
system 10 will be described in terms of a credit card 
transaction between a cardholder and a merchant and will 
include the financial institution ( s ) operating between these 

30 parties. 

[00014] Transaction processing system 10 is used in many 
financial transactions involving purchase of goods and services 
by credit card or other electronic transfer of funds. 
Consumers use credit cards to purchase goods and services from 
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merchants and service providers. Businesses and government 
agencies use electronic fund transfers to acquire goods and 
services and issue credit cards to employees as necessary to 
conduct business. 

[00015] Transaction processing system 10 is a. computer-based 
communication and transaction processing network with 
electronic links between parts of the system. Each of the 
communication links described herein can be direct hard-wired 
lines, leased high bandwidth lines, telephone lines, fiber 
optic cable, wireless, satellite, or the like. 
[00016] Transaction processing system 10 includes a 
relationship between cardholder 12 and issuing bank 14. 
Cardholder 12 can be an individual, corporation, or other legal 
entity that establishes a line of credit with issuing bank 14 
based on their credit rating and credit risk. Issuing bank* 14 
issues a credit card or other credit instrument to cardholder 
12. Cardholder 12 has the ability to purchase goods and 
services and otherwise pay debts using the credit card, within 
the limits imposed by issuing bank 14. Issuing bank 14 assumes 
responsibility to make good on any charge or debt properly 
incurred by cardholder 12 within established credit limits. 
Cardholder 12 agrees to pay the amount due on the credit card 
statement, or minimum portion thereof with interest on the 
balance, to issuing bank 14. 

[00017] With credit card in* hand, cardholder 12 can conduct 
business and make purchases with most business entities. For 
example, cardholder 12 can enter the place of business of 
merchant 20 and purchase goods or services with the credit 
card. Alternately, cardholder 12 may make purchases over the 
telephone or on-line via merchant 20' s internet website. FIG. 
1 illustrates the interactive commercial relationship between 
cardholder 12 and merchant 20 by link 22. 

[00018] Cardholder 12 makes his or her purchase selection (s) 
and provides the credit card to merchant 20. Merchant 20 
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swipes the credit card through a terminal to read the 
information stored on the magnetic strip, or enters the credit 
card number into the terminal keypad, or calls-in the credit 
card number by telephone into a processing center. The 
merchant's terminal is connected to acquiring bank 24 by 
electronic communication link 26. 

[00019] Merchant 20 has an account or relationship with 
acquiring bank 24. A transaction between cardholder 12 and 
merchant 20 involves the transmission of data from merchant 20 
to acquiring bank 24 by way of communication link 26. The 
transaction data includes (1) identification and other 
information related to cardholder 12 as read from the magnetic 
strip on the back of the credit card, (2) identification and 
other information related to merchant 20, and (3) the amount of 
the purchase or transaction. The cardholder information may 
include name, address, primary account number, PIN number, 
fraud protection data, etc. The transmission of data is 
encrypted to prevent fraud and unauthorized access to sensitive 
and confidential information related to cardholder 12 and 
merchant 20 . 

[00020] Acquiring bank 24 processes the transaction by making 
a record in its computer database, and possibly re-formatting 
the data or adding additional information according to its own 
procedures. Acquiring bank 24 may use a third party processor 
for some or all of its transaction processing functions. In 
the present example, the transaction is routed to transaction 
processing center 30 over communication link 32. In other 
applications, merchant 20 may have a direct relationship with 
transaction processing center 30 as shown by communication link 
28. 

[00021] Transaction processing center 30 is a third party 
service provider that acts for or on behalf of acquiring bank 
24 or merchant 20 as an interface to credit card association 
34. The role and function of transaction processing center 30 
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will be further discussed below. Transaction processing center 
30 processes the transaction and routes the processed 
transaction over communication link 36 to card association 34. 
Card association 34 includes well-known institutions identified 
by names such as Visa and MasterCard. Card association 34 
operates between acquiring bank 24 and issuing bank 14 to 
coordinate and simplify the large number of credit card 
transactions occurring on a daily basis. 

[00022] Card association 34 routes the transaction to issuing 
bank 14 over communication link 40. FIG. 1 assumes that the 
similar activities and operation of a transaction processing 
center like 30 are incorporated within issuing bank 14. In an 
alternate embodiment, a third party transaction processing 
center can be positioned between issuing bank 14 and card 
association 34 to provide some or all of the features described 
for transaction processing center 30. 

[00023] Issuing bank 14 has primary authority and assumes the 
principal risk of approving and settling the transaction. 
Issuing bank 14 processes the transaction and routes the 
response back through communication link 40 to card association 
34. Card association 34 routes the response from issuing bank 
14 back through communication link 36 to transaction processing 
center 30, which in turn communicates the issuing bank's 
response back to acquiring bank 24 by communication link 32. 
Merchant 20 receives the issuing bank's response to the 
transaction from acquiring bank 24 by communication link 26. 
[00024] As mentioned, there are variations to the above 
process. By way of example, in certain situations and with 
certain arrangements, transaction processing center 30 may 
communicate directly with issuing bank 14 as shown by 
communication link 44. Transaction processing center 30 may 
receive a transaction generated by merchant 20 and respond back 
to acquiring bank 24 by communication link 46 or directly back 
to merchant 20 by communication link 28. In communicating 
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directly with merchant 20, transaction processing center 30 may 
assume part or all of the authority and have procedures in 
place to accept the risk and responsibility for approving and 
processing the credit card transaction. In addition, third 
party service providers can operate at many points along the 
transaction processing route. Nonetheless, even given these 
and other variations on a central theme, in most cases, the 
basic credit card transaction process remains as described 
above . 

[00025] As an illustration of transaction processing system 
10, assume credit card transaction A is defined as cardholder 
12 being an individual and citizen from the United Kingdom (UK) 
traveling in the United States (US) on business and making a 
purchase from a merchant in a US city. Issuing bank 14 is a UK 
national bank and acquiring bank 24 is a US national bank. 
Transaction processing center 30 is a third party service 
provider with communication links to acquiring bank 24 and card 
association 34 as described above. Card association 34 sits 
between issuing bank 14 and transaction processing center 30. 
Transaction processing center 30 operates on behalf of 
acquiring bank 24 and merchant 20 -as an interface to card 
association 34. 

[00026] In credit card transaction A, cardholder 12 enters 
the place of business of merchant 20 with credit card in hand 
to purchase goods or services. Cardholder 12 makes his or her 
purchase selection (s) and provides the credit card to merchant 
20. Merchant 20 swipes the credit card through a terminal to 
read the information stored on the magnetic strip. At this 
point in the process, where cardholder 12 is directly 
interacting with merchant 20, the transaction is a purchase 
authorization request. The purchase authorization checks to 
see that the cardholder is in good-standing with the bank, that 
the purchase is within his or her approved credit limit, and 
that there are no other irregularities. No monies change hands 
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or accounts between cardholder 12 and merchant 20 at the point 
of sale. Instead, merchant 20 is simply requesting 
authorization for the amount of the purchase. Often times, 
merchant 20 does not know, understand, or even care who or what 
5 is approving the authorization. Merchant 20 just wants the 

purchase authorization to come back fast and be approved. The 
obligation and reputation of the financial entity, identified on 
the credit card or other entity who assumes the risk of the 
transaction gives merchant 20 confidence that payment is in 

10 fact forthcoming. 

[00027] The purchase authorization request includes (1) 
identification and other information related to cardholder 12 
as read from the magnetic strip on the back of the credit card, 
(2) identification and other information related to merchant 

15 20, and (3) the amount of the purchase or transaction. The 

cardholder information may include name, address, primary 
account number, PIN number, fraud protection data, etc. The 
purchase authorization request is encrypted to prevent fraud 
and unauthorized access to sensitive and confidential 

20 information, related to cardholder 12 and merchant 20. 

[00028] The purchase authorization request is routed across 
communication link 26 to acquiring bank 24. Acquiring bank 24 
processes the request by making a record in its computer 
database, and possibly re-formatting the authorization request 

25 or adding additional information according to its own 

procedures. The purchase authorization request is routed to 
transaction processing center 30 over communication link 32. 
Transaction processing system 30 routes the purchase 
authorization request over communication link 36 to card 

30 association 34. Card association 34 forwards the purchase 

authorization request to issuing bank 14 by communication link 
40. Issuing bank 14 then approves or denies the purchase 
authorization for the requested amount and routes the approval 
or denial back through card association 34, transaction 
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processing center 30, and acquiring bank 24 to merchant 20 in 
the reverse order previously described. If the purchase 
authorization is approved, cardholder 12 and merchant 20 
complete their transaction. Cardholder 12 leaves the store 
5 with the merchandise and a record of the transaction and 

merchant 20 receives assurance that the money will be paid. If 
the purchase authorization request is denied, cardholder 12 can 
offer another form of payment or forego the purchase. 
[00029] The authorizing institution is typically issuing bank 

10 14, although acquiring bank 24 or transaction processing center 

30 may assume that role in certain circumstances and under 
certain arrangements in which it chooses to bear the 
responsibility and risk of the credit card transaction. For 
example, transaction processing center 30 may respond directly 

15 to the authorization request back to acquiring bank 24 over 

communication link 46. Acquiring bank 24 would then notify 
merchant 20. Alternately, the purchase authorization request 
from merchant 20 may go directly to transaction processing 
center 30 by communication link 28 for approval. Transaction 

20 processing center 30 would approve or deny the purchase 

authorization request and send the approval or denial back to 
merchant 20 over communication link 28. 
[00030] Clearing and settlement is another type of 
transaction that can be processed through transaction 

25 processing system 10. The transfer and exchange of money, 

sometimes in different currencies, can be a time consuming, 
expensive, and error prone process. The aggregation of 
purchases and payment of net proceeds to the parties during 
clearing and settlement is a more efficient and cost effective 

30 alternative to exchanging money for each transaction. Clearing 

and settlement may occur at the end of the day, or at regular 
intervals during the day, or once every few days depending on 
the volume of transactions and needs of the parties. 
[00031] In clearing and settlement, monies actually exchange 
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hands by electronic transfer between accounts to complete 
previously approved but as of yet unsettled transactions. A 
number of purchase authorization requests like transaction A 
are approved throughout the day or other periods of time as 
5 determined by merchant 20 or acquiring bank 24. During 

clearing and settlement, an aggregation of the individual 
purchase requests is processed through transaction processing 
system 10 to fund previously approved transactions. 
[00032] Merchant 20 initiates a clearing and settlement 

10 transaction in many cases at the end of the business day. The 

clearing and settlement transaction includes and represents 
specific credit card transactions, including transaction A, 
which have been approved and accrued since the last clearing 
and settlement transaction. The clearing and settlement 

15 transaction is routed from merchant 20 to acquiring bank 24 by 

communication link 26. If merchant 20 is a large institution, 
or if merchant 20 has special- arrangements with acquiring bank 
24, then acquiring bank 24 may forward the single clearing and 
settlement transaction for merchant 20 to transaction 

20 processing center 30. Alternatively, acquiring bank 24 may 

accumulate a number of clearing and settlement transactions 
from smaller merchants before forwarding an aggregate clearing 
and settlement transaction to transaction processing center 30. 
[00033] Transaction processing center 30 processes the 

25 clearing and settlement transaction and forwards the processed 

transaction to card association 34. Card association 34 
accumulates clearing and settlement transactions from a number 
of sources, e.g. other acquiring banks or other transaction 
processing centers, which are intended for each issuing bank. 

30 The clearing and settlement transaction from merchant 20 

intended to clear and settle transaction A, along with other 
transactions from merchant 20 and from other merchants and from 
other acquiring banks, each intended for issuing bank 14, are 
accumulated, sorted, processed, and routed to issuing bank 14 
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by card association 34. 

[00034] Issuing bank 14 reviews the aggregate clearing and 
settlement transaction from card association 34 and, if all is 
in order with the pre-approved authorization requests, executes 
a wire transfer of funds, or authorizes deduction from accounts 
established within card association 34, for payment of the 
specific approved transactions made during the clearing and 
settlement period with merchants that have transacted with 
cardholders using credit cards issued by issuing bank 14. In 
other words, the funds paid by issuing bank 14 will be 
sufficient to cover payments which card association 34 must 
make to specific acquiring banks to cover monies due to 
merchants, for authorized purchases made by cardholders using 
credit cards issued by issuing bank 14. Issuing bank 14 sends 
credit card statements on a periodic basis, e.g. monthly, to 
its cardholders for the purchases made during the period as 
shown by link 48. Issuing bank 14 assumes the risk whether the 
cardholder will pay the bill. Issuing bank' 14 earns its 
revenue from service charges, fees and interest charges 
.received from cardholders on any unpaid balance due on the 
statements. 

[00035] The issuing banks belonging to card association 34 
make payment thereto to clear and settle specific pre-approved 
outstanding transactions. Card association 34 then makes 
payments to specific acquiring banks with the funds received 
from the issuing banks. One of those payments from card 
association 34 will go through transaction processing center 30 
to acquiring bank 24. Acquiring bank 24 then credits the 
account of merchant 20 for transaction A. That is, a portion 
of the payment made by card association 34 to acquiring bank 24 
by way of transaction processing center 30 will be used to pay 
merchant 20 for transaction A. 

[00036] A principal function of card association 34 is to act 
as a funding clearing house for clearing and settlement. 
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Issuing bank 14 may need to pay monies to a large number of 
acquiring banks, and acquiring bank 24 may expect to receive 
monies from a large number of issuing banks. By operating 
through card association 34, issuing bank 14 makes one wire 
transfer or authorization to debit its account to card 
association 34 who in turn makes payments to specific acquiring 
banks. Likewise,, acquiring bank 24 receives one wire transfer 
from card association 34 to settlement transactions for 
specific issuing banks. 

[00037] Yet another type of transaction that can be processed 
through transaction processing center 30 is a purchase 
authorization request which automatically triggers clearing and 
settlement at the end of the day or other time interval without 
any further post authorization transaction. Transaction 
processing center 30 can be set up to keep track of each 
purchase authorization request, which will include, clearing and 
settlement data. At a predetermined interval, transaction 
processing center 30 will automatically generate a process to 
clear and settle some or all of the outstanding purchase 
authorization requests. The automatic clearing and settlement 
can also be initiated in or by card association 34 . 
[00038] The activities and operation of transaction 
processing center 30 will now be discussed in further detail. 
As shown in FIG . 1, transaction processing center 30 is 
positioned between acquiring bank 24 and card association 34. 
Transaction processing center 30 uses direct electronic 
communication links with acquiring bank 24 and card association 
34, and in some applications directly with merchant 20 and 
issuing bank 14. Transaction processing center 30 can be a 
third party service provider as shown in FIG. 1 operating on 
behalf of and providing services for acquiring bank 24, or the 
activities and operation of transaction processing center 30 
can be incorporated within acquiring bank 24 or even merchant 
20. 
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[00039] Transaction processing system 10 has been and will be 
described in terms of a credit card transaction for the purpose 
of illustration. Transaction processing system 10 is also 
applicable to any type of transaction involving the transfer 
5 and processing of data. For example, transaction processing 

system 10 could be utilized in airline, hotel, rental car, and 
ticketing reservation systems. Transaction processing system 
10 has applications in manufacturing and supply chain 
management . 

10 [00040] Turning to FIG. 2, transaction processing center 30 

is shown to include two data processing channels. A first data 
processing channel is intended for message-based transactions, 
such as purchase authorization requests and other messages 
where time and speed are of the essence. Authorization process 

15 52, data storage device 54 and authorization process 56 are 

shown as exemplary data processing functions in the first data 
processing channel. It is understood that other data 
processing functions could be implemented in the first data 
processing channel. A second data processing channel is 

20 intended for file-based transactions, such as clearing and 

settlement and reports. Post authorization process 60, data 
storage device 54 and post authorization process 62 are shown 
as exemplary data processing functions in the second data 
processing channel. It is understood that other data 

25 processing functions could be implemented in the second data 

processing channel. The first and second data processing 
channels each provide a number of data processing functions, 
such currency conversions in any one of a plurality of 
selectable currencies. 

30 [00041] Transaction processing center 30 further includes 

data transfer process 50 having a first portion and a second 
portion. A transaction or other data from acquiring bank 24 
(or from merchant 20) is received on communication link 32 (or 
communication link 28) and processed through the first portion 
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of data transfer process 50 labeled as 50a. Data transfer 
process 50a separates message-based transactions, such as 
purchase authorization requests, from file-based transactions, 
such clearing and settlement and reports, for processing in 
5 their respective data processing channels through transaction 

processing center 30. 

[00042] A transaction determined to be a purchase 
authorization request is routed from data transfer process 50a 
through a purchase authorization channel including 

10 authorization process 52, data storage device "54, and 

authorization process 56. Authorization process 52 performs 
parsing and formatting of the purchase authorization request 
for local storage in data storage device 54. Authorization 
process 52 may also perform other data processing functions 

15 such as currency conversion, reporting, error checking, and 

other administrative functions on the purchase authorization 
request. The purchase authorization request is stored in data 
storage device 54 for reporting, account reconciliation, and 
general record keeping and transaction visibility. Data 

20 storage device 54 is a high capacity relational database 

utilizing a mass storage medium such as a hard disk drive, 
optical drive, or the like. The purchase authorization request 
is then routed through authorization process 56 where the 
request is formatted and any additional information added to 

25 the authorization request as necessary for transfer to card 

association 34. The second portion of data transfer process 50 
labeled as 50b sends the properly formatted purchase 
authorization request to card association 34 by way of 
communication link 36. Data transfer process 50b may send the 

30 properly formatted purchase authorization request directly to 

issuing bank 14 by way of communication link 44. 
[00043] The reverse process holds true for responses from 
issuing bank 14 to the purchase authorization request. The 
response from issuing bank 14 is forwarded by card association 
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34 to transaction processing center 30. A transaction 
determined to be a response to a purchase authorization request 
is routed from data transfer process 50b through the purchase 
authorization channel. Authorization process 56 performs 
5 parsing, formatting, currency conversion, reporting, error 

checking, and other administrative functions for the response 
to the purchase authorization request prior to local storage in 
data storage device 54. The response to the purchase 
authorization request is stored in data storage device 54 for 

10 reporting, account reconciliation, and general record keeping 

and transaction visibility. The response to the purchase 
authorization request is then routed through authorization 
process 52 where the "request is formatted and any additional 
information added to the response for transfer to .acquiring 

15 bank 24 or merchant 20. Data transfer process 50a sends the 

properly formatted response to the purchase authorization 
request to acquiring bank 24 or merchant 20. 

[00044] The af oredescr ibed purchase authorization channel 
through transaction processing center 30 is a dedicated 

20 communication link that is always open and active to provide 

for fast processing of purchase authorization requests. In a 
practical, real-time system, the purchase authorization request 
sent by merchant 20 must (1) traverse acquiring bank 24, 
transaction processing center 30, and card association 34 to 

25 issuing bank 14, (2) be approved or denied by issuing bank 14, 

and (3) be sent back through card association 34, transaction 
processing center 30, and acquiring bank 24 to merchant 20, all 
within a matter of seconds to meet the expectations of 
cardholder 12 and merchant 20. If the purchase authorization 

30 request is perceived to be excessively time consuming, 

cardholder 12 and merchant 20 may become discouraged from using 
a credit card for the purchase of goods and services. Thus, a 
quick purchase authorization request approval time is important 
to the success of transaction processing system 10. If the 
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authorization process takes too long, cardholder 12 could 
become reluctant to using the convenience and safety of a 
credit card. Merchant 20 could lose sales from buyers who are 
inclined to make purchases with a credit card. The issuing 
5 bank and acquiring bank could lose interest and fees derived 

from each credit card transaction. 

[00045] As previously discussed, transaction processing 
center 30 also processes clearing and settlement transactions 
for acquiring bank 24 and merchant 20. The clearing and 

10 settlement transaction is procedural different than the 

purchase authorization request and therefore is shown with its 
own processing channel. Whereas the purchase authorization 
process is a real-time, message-based transaction with speed of 
the essence, the clearing and settlement transaction is 

15 typically a file-based transaction processed as a batch file of 

multiple transactions where time is not a critical factor. 
[00046] Data transfer process 50 separates message-based 
transactions, such as purchase authorization requests, from 
file-based transactions, such clearing and settlement, for 

20 processing in their respective data processing channels through 

transaction processing center 30. Data transfer process 50 may 
examine different attributes or features to determine whether a 
transaction is message-based or file-based. For example, 
message-based transactions have structural and formatting 

25 differences from file-based transaction. In other situations, 

the method or mode of receipt of the transaction will indicate 
whether it is message-based or file-based. 

[00047] A transaction determined by data transfer process 50a 
to be a clearing and settlement process is routed through a 
30 file-based data processing channel including post authorization 

process 60, data storage device 54, and post authorization 
process 62. Post authorization process 60 performs parsing and 
formatting of the clearing and settlement transaction for local 
storage in data storage device 54. Post authorization process 
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60 may also perform other functions such as currency 
conversion, reporting, error checking, and other administrative 
functions on the clearing and settlement transaction. The 
clearing and settlement transaction is stored in data storage 
device 54 for reporting, account reconciliation, and general 
record keeping and transaction visibility. The clearing and 
settlement transaction is then routed through post 
authorization process 62 where the request is formatted and any 
additional information added to the transaction as necessary 
for transfer to card association 34. Data transfer process 50b 
sends the properly formatted clearing and settlement 
transaction to card association 34 by way of communication link 
36. Data transfer process 50b may send the properly formatted 
-clearing and settlement transaction directly to issuing bank 14 
by way of communication link 44. 

[00048] The reverse process holds true for responses from 
issuing bank 14 to the clearing and settlement transaction. 
The response from issuing bank 14 to the clearing and 
settlement transaction may be a wire transfer of funds or 
authorization for card association 34 to debit the issuing 
bank 7 s account and forward funds to transaction processing 
center 30. The funds are in turn sent to acquiring bank 24 to 
credit the account of merchant 20 for purchases made by 
cardholder 12. Any transaction determined by data transfer 
process 50b to be a response to a clearing and settlement 
transaction is routed from data transfer process 50b to post 
authorization process 62. Post authorization process 62 
performs parsing, formatting, currency conversion, reporting, 
error checking, and other administrative functions for the 
response to the clearing and settlement transaction prior to 
local storage in data storage device 54. The response to the 
clearing and settlement transaction is stored in data storage 
device 54 for reporting, account reconciliation, and general 
record keeping and transaction visibility. The response to the 
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clearing and settlement transaction is then routed through post 
authorization process 60 where the response is formatted and 
any additional information added to the response for transfer 
to acquiring bank 24 and finally to merchant 20. Data transfer 
process 50a sends the properly formatted response to the 
clearing and settlement transaction to acquiring bank 24 or 
merchant 20. 

[00049] Transaction processing center 30 is shown in FIG. 2 
to include authorization processes 52 and 56 for processing 
purchase authorization requests as one type of message-based 
transaction and post authorization processes 60 and 62 for 
processing clearing and settlement as one type of file-based 
transaction. Authorization processes 52 and 56 are readily 
expandable to handle other types of data processing functions 
for other message-based transactions. Likewise, post 
authorization processes 60 and 62 are readily expandable to 
handle other types of data ■ processing functions for other file- 
based transactions. 

[00050] Acquiring bank 24; issuing bank 14, and card 
association 34 may send administrative transactions back and 
forth through transaction processing center 30. The 
administrative transactions include reports, account 
reconciliation, refunds, charge-backs, inquiries, error 
messages, and other administrative functions. A transaction 
determined by data transfer process 50a to be an administrative 
transaction can be routed to either authorization process 52 or 
to post authorization process 60 depending on whether the 
administrative transaction is message-based or file-based. If 
the administrative transaction is file-based, post 
authorization process 60, operating in its expanded role, 
performs parsing and formatting of the administrative 
transaction for local storage in data storage device 54. The 
administrative transaction is stored in data storage device 54 
for reporting, account reconciliation, and general record 
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keeping and transaction visibility. 

[00051] In some cases, the administrative transaction is 
processed and sent back to the initiator. For one example, 
merchant 20 may request a report of transactions incurred over 
5 some period of time which is generated by transaction 

processing center 30 from the data stored in data storage 
device 54. The report is then sent back to merchant 20. In 
another example of a message-based transaction which is 
processed through authorization processes 52 and 56, operating 
10 in their expanded role, acquiring bank 24 may request a current 

quote on currency exchange rates being applied by transaction 
processing center 30. Again, the quote is generated and 
returned to acquiring bank 24. 

[00052] Other times the administrative transaction must be 

15 forwarded to card association 34. For example, cardholder 12 

may return the merchandise and merchant 20 must process a 
refund. In another example, acquiring bank 24 may detect an 
error during account reconciliation and request a correction by 
card association 34. In such cases, the administrative 

20 transaction is then routed through post authorization process 

62 (or, if message-based, through authorization process 56) 
where the request is formatted and any additional information 
added to the transaction as necessary for transfer to card 
association 34. Data transfer process 50b sends the properly 

25 formatted administrative transaction to card association 34 by 

way of communication link 36. In some cases, card association 
34 will handle the administrative transaction and, in other 
cases, card association 34 will forward the transaction to 
issuing bank 14. Data transfer process 50b may send the 

30 properly formatted administrative transaction directly to 

issuing bank 14 by way of communication link 44. 
[00053] The reverse process holds true for responses from 
card association 34 or issuing bank 14 to the administrative 
transaction. Any transaction determined by data transfer 
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process 50b to be a response to an administrative transaction 
is routed from data transfer process 50b to post authorization 
process 62 (or authorization process 56) . Post authorization 
process 62 performs parsing, formatting, reporting, error 
checking, and other administrative functions for the response 
to the administrative transaction prior to local storage in 
data storage device 54 . The response to the administrative 
transaction is stored in data storage device 54 for reporting, 
account reconciliation, and general record keeping and 
transaction visibility. The response to the administrative 
transaction is then routed through post authorization process 
60 (or authorization process 52) where the response is 
formatted and any additional information added to the response 
for transfer to acquiring bank 24 and finally to merchant 20. 
Data transfer process 50a sends the properly formatted response 
to the administrative transaction to acquiring bank 24 or 
merchant 20. 

[00054] A simplified representation of transaction processing 
center 30, including data transfer process 50a and 50b 
(collectively referred to as data transfer process 50) , is 
shown in FIG. 3. Data source 70 represents the incoming 
transactions and data from acquiring bank 24 or merchant 20. 
For a message-based transaction, the" type of message or 
contents of the message or the mode of receipt determines the 
data processing, path through transaction processing center 30. 
For example, a purchase authorization request is a type of 
message that, because of its need for speedy processing, is 
handled by data transfer process 50 and transaction processing 
center 30 in a time critical manner. Message-based data, such 
as the purchase authorization request, is routed directly 
through the message-based data processing channel 72 of 
transaction processing center 30. In the case of the purchase 
authorization request, the message-based data processing is 
immediately routed through the open and active processing 
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channel comprising authorization processes 52 and 56 and data 
storage device 54. The purchase authorization request 
information is rapidly processed within transaction processing 
center 30, including any necessary parsing, formatting, 
currency conversion, reporting, error checking, data storage, 
and other administrative functions. 

[00055] Another example of message-based data processing is 
one that is controlled by the contents of the message such as a 
high priority request 'for currency exchange rates. Since 
exchange rates may change rapidly in real-time, it is important 
to get a quick response to have the most up-to-date and 
accurate information. 

[00056] Message-based data processing channel 72 will rout 
the data being processed to data destination 74 which may be 
card association 34 or issuing bank 14. Alternatively, data 
destination 74 can be acquiring bank 24 or merchant 20 if the 
message-based data processing is intended to return to the 
initiator. 

[00057] Another feature of data transfer process 50 is shown 
as file-based data processing channel 76. If the data received 
from data source 70 is a file, then information contained in or 
attributes associated with the file determine the processing 
path for the data in the file. For example, the file may 
contain a field that includes a file number. The file number 
will determine how the data in the file is to be processed 
through transaction processing center 30. Alternatively, the 
file may contain a status field which will determine how the 
data in the file is to be processed through transaction 
processing center 30. Other attributes of the file such as its 
file name or file extension or type of file or date of creation 
or owner of the file or size of the file can be used to 
determine how the data in the file is to be processed through 
transaction processing center 30. As further explained in FIG. 
5 and associated text, file-based data processing channel 76 
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over an FTP connection. Other files may be formatted according 
to one of the MasterCard file formats and then transferred 
across communication link 32 or 28 over a secure socket layer 
(SSL) connection. A file can be an aggregation of clearing and 
settlement transactions from acquiring bank 24 from many 
different merchants. A clearing and settlement transaction 
file will contain one or more individual transactions from one 
or more merchants. Each clearing and settlement transaction 
may contain credit card number and other information related to 
the cardholder, identity and information related to the 
merchant/ and the amount of the transaction. A file can 
contain a request for a report by acquiring bank 24 or merchant 
20. A file can also contain account reconciliation requests or 
error corrections or refund transactions or administrative 
functions. 

[00061] Data processing 82 represents one or more computer 
systems each with one or more central processing units (CPUs) 
and each operating software to control access to incoming queue 
80. Each CPU can be operating a different process. Data 
processing 82 may be one or more servers local to transaction 
processing center 30 or it may be distributed to multiple 
computer systems with communication links to remote locations. 
Data processing 82 sends and receives data from data storage 
device 54. The software operating on the one or more CPUs of 
data processing 82 will examine incoming queue 80 and retrieve 
files for processing based on the contents of the file or 
attributes of the file. For example, a first CPU in data 
processing 82 may query incoming queue 80 looking for files or 
groups of files containing a certain file number or status. 
Files with file number 100 may be clearing and settlement 
transactions which the first CPU will process accordingly. A 
second CPU in data processing 82 may query incoming queue 80 
looking for files or groups of files having certain file 
extensions or creation dates or other file attributes. Files 
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with a file extension of say " . REQ" may be a request for a 
report. The second CPU processes the request for report and 
forwards the report to the requester. 

[00062] The CPUs of data processing 82 may be dedicated to 
processing certain types of files or they may share 
responsibilities. The CPUs of data processing 82 which are 
idle, i.e. no primary files to process, can be temporarily re- 
assigned to processing other types of files on a secondary 
basis until some primary files need to be processed. 
Alternately, a prioritization scheme can be established such 
that each CPU in data processing 82 in turn takes the next file 
or group of files from incoming queue 80 based on the hierarchy 
of the prioritization scheme. The CPUs will be fully utilized, 
each backing up the other for maximum data throughput. 
[00063] Data processing 82 processes the data with each file 
according to its procedures and the contents of the file. In 
the above example of a clearing and settlement transaction 
file, data processing 82 parses the data, perform currency 
conversions and error checking, adds information, reformats 
data as necessary, and performs other administrative functions. 
Data processing 82 will access data storage device 54 as 
necessary to perform the data processing function. A process 
in data processing 82 will then place the processed clearing 
and settlement transaction data file in outgoing queue 84. In 
a similar manner for the report request file, data processing 
82 parses the data, retrieves data from data storage device 54, 
performs error checking, adds information, reformats data as 
necessary, and performs other administrative functions. Data 
processing 82 then places the processed report file in outgoing 
queue 84 . 

[00064] The files in outgoing queue 84 may be transferred to 
data destination 74 in a variety of ways. Transaction 
processing center 30 may send the files by way of one of its 
communication links to data destination 74. Alternatively, 
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data destination 74 may initiate the transfer after receiving a 
notice of "file ready for transfer" instruction from 
transaction processing center 30. Data destination 74 may poll 
or query outgoing queue 84 at predetermined times or after a 
given time since the original request file was placed in 
incoming queue 80. In other embodiments, incoming queue 80 may 
physically reside at data source 70 and outgoing queue 84 may 
physically reside at data destination 74. In this case, data 
processing 82 would access the files stored in incoming queue 
80 on data source 70' s server. Data processing 82 then places 
processed files in outgoing queue 84 on data destination 74' s 
server. 

■ [00065] FIG. 5 illustrates the steps involved in the 
operation of file-based data processing channel 76. Step 86 
stores files from data source 70 in incoming queue 80. Step 88 
selects a file from incoming queue 80 based on the contents or 
attributes of the file. Step 90 processes data from the file 
through data processing 82. Step 92 stores the processed data 
from data processing 82 in an outgoing file. Step 94 stores 
the outgoing file in outgoing queue 84 for access by data 
destination 74. Step 96 provides first and second CPUs in data 
processing 82. Step 98 utilizes the first CPU to select the 
file from incoming queue 80 based on a first selection 
criteria. The first selection criteria may involve selecting 
files or groups of files containing a certain file number or 
status or other contents of the file. Step 102 utilizes the 
second CPU to select the file to be placed into outgoing queue 
84 based on a second selection criteria. The second selection 
criteria may involve selecting files or groups of files based 
on file name extension or other file attribute. 
[00066] The operation of file-based data processing channel 
76 simplifies the data processing through transaction 
processing center 30. Incoming queue 80 allows many types of 
files to be received and made available for processing without 
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knowledge of the complexity, structure, or function associated 
with each type of file. Data processing 82 can operate with 
multiple CPUs. Each CPU can be operating the same software 
which is configurable to query and access files in incoming 
queue 80 according to many file processing protocols, e.g. 
dedicated file processing responsibilities, or hierarchical 
processing based on some prioritization scheme, or any other 
file processing ordering. Therefore, the structural and 
functional knowledge associated with incoming queue 80 is 
minimal. Data source 70 need not be concerned with interfacing 
with data processing 82. Data source 70 need only place a data 
file in incoming queue 80. Incoming queue 80 may know it has 
one or more files stored in its stack, but has no idea of the 
contents, structure, or function of the files.- The CPUs of 
data processing 82 need not be concerned with interfacing with 
a number of requesters and data sources. The CPUs interface 
only with incoming queue 80. The CPUs simply query incoming 
queue 80 and access the file or group of files based on 
predefined file processing protocols. 

[00067] Likewise, outgoing queue 84 allows many types of 
files to be received and made available for processing without 
knowledge of the complexity, structure, or function associated 
with each type of file. • Each CPU can be operating the same 
software which is configurable to place processed files in 
outgoing queue 84 according to many file processing protocols, 
e.g. hierarchical processing based on some prioritization 
scheme or any other file process ordering. Therefore, the 
structural and functional knowledge associated with outgoing 
queue 84 is minimal. Data destination 74 need not be concerned 
with interfacing with data processing 82. Data destination 74 
need only extract a data file from outgoing queue 84. Outgoing 
queue 84 may know that one or more files are stored in its 
stack, but has no idea of the contents, structure, or function 
of the files. The CPUs of data processing 82 need not be 
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concerned with interfacing with a number of data destinations. 
The CPUs interface only with outgoing queue 84. The CPUs 
simply places processed files or groups of files into outgoing 
queue 84- for access by data destination 74 based on predefined 
file processing protocols. 

[00068] Transaction processing center 30 provides significant 
flexibility as to where resources are placed and who requests 
information and receives data. The incoming queue and outgoing 
queue simplify the interface and processing for data processing 
82 as well as for data source 70 and data destination 74. 
[00069] The previous examples have discussed several types of 
data processing functions that are performed within transaction 
processing center 30. One of the data processing steps that is 
performed for purchase authorization requests and for clearing 
and settlement transaction within both data processing channels 
of transaction processing center 30 is currency conversion. It 
is an obvious fact that cardholder 12 and merchant 20 must deal- 
in a world economy. There are many countries and many 
different currencies throughout the world. The simple 
transaction A previously discussed involves at least two 
countries, i.e. US and UK, and their respective currencies. 
Transaction processing center 30 provides flexibility as to 
how, when and by what exchange rate one currency is converted 
to another currency, and to whom fees are accessed for the 
currency conversion. 

[00070] Transaction processing center 30 receives timely 
currency exchange rates from the financial markets. Currency 
exchange rate source 64 in FIG. 2 represents one or more 
sources from the financial markets that set or monitor currency 
exchange rates. The most current exchange rates are sent to 
currency exchange rate importer 66 which parses and formats the 
currency exchange rates for local storage in data storage 
device 54. The current exchange rates stored in data storage 
device 54 are used for currency conversion as described 
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hereinafter . 

[00071] FIG. 6 illustrates a basic block diagram of the 
logical flow of the transaction with a number of currency 
conversions. Associated with the entities defined in FIG. 1 
there are default settings which collectively are used in 
determining currency conversions. Transaction processing 
center 30 records these settings in its system for use in the 
currency conversion process and assessment of fees associated 
therewith. Merchant 20 has settings such as the default 
merchant funding currency which define the currency in which he 
or she would like to be paid and the default request currency 
which is the currency of the merchandise price quote, i.e. the 
amount of money that the merchant is expecting to receive. 
Acquiring bank 24 has settings such as acceptable exchange 
rates. Card association 34 has a number of settings and rules 
by which it operates. Issuing bank 14 has settings such as 
mark-up and mark-down for the monetary values of the 
transactions . 

[00072] Returning to the exemplary transaction A, when 
merchant 20 submits the purchase authorization request 
directly, or through acquiring bank 24, to transaction 
processing center 30 there is a request currency 120 associated 
with the purchase amount. Request currency 120 can be any 
currency denomination selectable by the merchant. Merchant 20 
expects to be paid a certain price or amount of money for the 
merchandise or service being purchased by cardholder 12. 
Merchant 20 selects request currency 120, or allows cardholder 
12 to select request currency 120, as the stated currency for 
the price or amount of money that the merchant is expecting to 
receive. In transaction A, given that merchant 20 is a US- 
based business operating with a US acquiring bank 24, merchant 
20' s settings are most likely and assumed to be United States 
Dollars (USD) for request currency 120. 

[00073] Since request currency 120 can be any currency 
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denomination from any country, a transaction currency 122 is 
provided and used as a baseline currency for account 
reconciliation, generating statements, making refunds, 
reporting functions, funding merchant 20, or processing through 
5 card association 34 and issuer 14. Many financial institutions 

prefer to deal in certain well-established and stable, 
currencies. Certain less stable currencies are difficult and 
problematic to reconcile and report against. Transaction 
currency 122 provides a basis, using a well-established 

10 currency as a baseline, to make adjustments following account 

reconciliation and provide useful reporting functions. For 
transaction A with a US-based acquiring bank 24, transaction 
currency 122 is USD. Therefore, since request currency 120 can 
be any currency denomination, transaction currency 122 is a 

15 useful step to allow for the flexibility in selecting the 

request currency while providing a vehicle to convert the 
request currency to one of the more established and accepted 
transaction currencies for reporting and reconciliation. . If 
necessary, transaction processing center 30 performs a currency 

20 conversion from request currency 120 to transaction currency 

122. Transaction processing center 30 may mark-up or mark-down 
on the monetary value of the transaction or otherwise access a 
fee for the currency conversion from request currency 120 to 
transaction currency 122 based on the system settings. Since 

25 request currency 120 is USD and transaction currency 122 is 

USD, there is no need for a currency conversion. 
[00074] At this point in the process, the purchase 
authorization request for transaction A exists in transaction 
processing center 30 in the form of transaction currency 122. 

30 Transaction processing center 30 will be able to store and 

process data, generate reports, reconcile the accounts, and 
perform further administrative processing based on transaction 
currency 122 independent of the form of request currency 120. 
[00075] Transaction processing center 30 also provides 
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match any other currency, including the native currency of 
issuing bank 14 which in most cases is the same as the billing 
currency of cardholder 12, prior to sending the transaction to 
card association 34. Transaction processing center 30 can 
5 establish multiple BINs with card association 34 for clearing 

currency 124, one for each currency to be used as clearing 
currency 124 . 

[00078] For transaction A, with the knowledge of the system 
settings of issuing bank 14 and cardholder 12, the purchase 

10 authorization request is converted from transaction currency 

122 to clearing currency 124 which may be a different currency 
than transaction currency 122. That is, the purchase 
authorization request is converted from USD to GBP by 
transaction processing center 30 prior to transfer' of the 

15 purchase authorization request to card association 34. 

Transaction processing center 30 selects the BIN associated 
with GBP when forwarding transaction A to card association 34. 
When the purchase authorization request is received by card 
association 34, the transaction . will be viewed as a 

20 conventional transaction in the native currency of the BIN for 

issuing bank 14, i.e. in GBP, with no need for card association 
.34 to perform any currency conversion or access any fees or 
make any mark-up or mark-down associated with a currency 
conversion. Transaction processing center 30 may mark-up or 

25 mark-down or otherwise access a fee on the monetary value of 

the transaction for a currency conversion from transaction 
currency 122 to clearing currency 124 based on the system 
settings related to merchant 20, issuing bank 14, acquiring 
bank 24, and card association 34. 

30 [00079] The currency conversion from transaction currency 122 

to clearing currency 124 is performed by transaction processing 
center 30, which is acting on behalf of acquiring bank 24 and 
merchant 20, prior to the purchase authorization request being 
transferred to card association 34. Merchant 20 is a customer 
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of acquiring bank 24. Although transaction processing center 
30 may access fees and mark-ups or mark-downs in the monetary 
value of the transaction based on system settings, transaction 
processing center 30 and acquiring bank 24 will both have a 
5 vested interest in providing maximum overall value in the 

transaction for merchant 20. By knowing the mark-up and mark- 
down of issuing bank 14 from its settings, transaction 
processing center 30 can research the open financial markets 
for better rates and provide the best service to its customers, 

10 i.e. acquiring bank 24 and merchant 20. 

[00080] Prior to transfer to card association 34, the 
purchase 'authorization request for transaction A exists in 
transaction processing center 30 in the form of clearing 
currency 124. Transaction processing center 30 will transfer 

15 the purchase authorization request to card association 34 with 

the amount of the transaction stated in clearing currency 124. 
The clearing currency 124 is selected, to match the native 
currency of issuing bank 14 and/or the billing currency of 
cardholder 12. In the situation where the native currency of 

20 issuing bank 14 is different from the billing currency to 

cardholder 12, clearing currency 124 may be selected to match 
the billing currency to cardholder 12 to avoid additional fees 
for currency conversion to the cardholder by the issuing bank 
or card association. When card association 34 receives the 

25 transaction, the purchase will appear to be a conventional 

transaction in the native currency of issuing bank 14, or at 
least the same currency as defined for the BIN which issuing 
bank 14 uses to conduct transactions with card association 34. 
[00081] For transaction A, clearing currency 124 is GBP,- 

30 Card association 34 requests the purchase authorization request 

be approved by issuing bank 14 in GBP. Issuing bank 14 checks 
cardholder 12' s credit card account based on the amount of the 
purchase authorization request in GBP. Issuing bank 14 
approves or disapproves the purchase authorization request 
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based on GBP and responds to card association 34. Card 
association 34 forwards the response to transaction processing 
center 30 with the approval or denial in settlement currency 
126 as determined by the acquiring BIN used by transaction 
processing center 30 for the transaction. Settlement currency 
126 is that currency which acquiring bank 24 wishes to receive 
from card association 34. Transaction processing center 30 can. 
establish multiple BINs with card association 34 for settlement 
currency 126, one for each currency to be used as settlement 
currency 126. As a final step, transaction processing center 
30 converts settlement currency 126 to merchant funding 
currency 128, if necessary. Merchant funding currency 128 is 
that currency in which merchant 20 wants to be paid. For 
transaction A, transaction processing center 30 has set 
settlement currency 126 and merchant funding currency 128 both 
to USDs at the request of and for the benefit of acquiring bank 
24 and merchant 20. Therefore, there is no need for a currency 
conversion. Merchant 20 receives the approved or denial to the 
purchase authorization request in USD. 

[00082] Assume the transaction between cardholder 12 and 
merchant 20 is approved and completed, the clearing and 
settlement of transaction A follows a similar path through the 
institutions. Request currency 120 for clearing and settlement 
is USD. Transaction currency 122 for clearing and settlement 
is USD. Transaction currency 122 is converted to GBP as 
clearing currency 124. The clearing and settlement transaction 
is sent to card association 34 in clearing currency 124, i.e. 
GBP. Card association 34 views the clearing and settlement as 
a transaction in issuing bank 14' s native or BIN currency.- 
There is no currency conversion, fees assessment, mark-up or 
mark-down by card association 34, even though cardholder 12 and 
merchant 20 are dealing in different currencies. Transaction 
processing center 30 has handled the currency conversion on 
behalf of merchant 20. Card association 34 sends the clearing 
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currency to issuing bank 14. Issuing bank 14 makes a wire 
transfer or authorizes debit against its account at card 
association 34 in the currency defined by the BIN used by 
issuing bank 14. Card association 34 makes a wire transfer or 
credits the account of transaction processing center 30 as 
defined by its BIN. Transaction processing center 30 receives 
monies for settlement of transaction A in settlement currency 
126, which is USD in the present example. Transaction 
processing center 30 converts the monies to merchant funding 
currency 128 if necessary and forwards the settlement to 
acquiring bank 24 to credit to merchant 20' s account or 
directly to merchant 20. Since settlement currency 126 and 
merchant funding currency 128 are the same, no currency 
conversion is necessary. 

[00083] Now consider a transaction B where cardholder 12 is 
making a purchase from merchant 20 over the internet. Merchant 
20 operates a website where merchandise is offered at any 
currency rate as selected by the customer. The customer pulls 
down a selection box on the computer screen and receives a 
price quote in the selected request currency. In this example, 
cardholder 12 is a US citizen living in Japan and merchant 20 
is French company. Acquiring bank 24 is a French national 
bank. Issuing bank 14 is a US national bank. Cardholder 12 
pays US-based issuing bank 14 is USD. Cardholder 12 selects 
the price to be paid for the merchandise on merchant 20' s 
website in Japanese Yen (JPY) to compare with local competitive 
pricing. Merchant 20 wants to be paid in Euro Dollars (EUR) . 
[00084] In FIG. 6, request currency 120 is JPY. Transaction 
currency 122 is EUR for the benefit of acquiring bank 24 and 
merchant 20. Transaction processing center 30 performs the 
currency conversion from request currency 120 in JPY to 
transaction currency 122 in EUR. Clearing currency 124 is 
selected to be USD so the transaction appears to be in the 
native currency of issuing bank 14 and cardholder 12. 
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Transaction processing center 30 performs the currency 
conversion from transaction currency 122 in EUR to clearing 
currency 124 in USD. Card association 34 receives a 
transaction in USD as the clearing currency. Issuing bank 14 
5 authorizes (or settles) the transaction in USD. Transaction 

processing center 30 elects to receive settlement currency 126 
from card association 34 in USD so that there is no currency 
conversion done by card association 34 . Transaction processing 
center 30 performs a currency conversion from settlement 

10 currency 126 in USD to merchant funding currency 128 in EUR. 

[00085] Merchant 20 should not be assessed any currency 
conversion fees or mark-ups or mark-downs by card association 
34 or issuing bank 14 because card association 34 and issuing 
bank 14 view the entire transaction as based in its native 

15 currency of USD with no currency conversion needed. Request 

currency 120, transaction currency 122, and clearing currency 
124 allow transaction processing center 30' to control the 
currency conversion on the transaction on the front end of the 
process and extract the most favorable exchange rate from the 

20 financial markets. Settlement currency 126 and merchant 

funding currency 128 allows transaction processing center 30 to 
control the currency conversion on the transaction on the back 
end of the process and extract the most favorable exchange rate 
from the financial markets. 

25 [00086] The BINs set up with card association 34 allow 

transaction processing center 30 to control the points in the 
transaction where currency conversion will occur. Transaction 
processing center 30 simply chooses the desired BIN in which to 
transfer the transaction. The currency conversion occurs by 

30 transaction processing center 30 placing a certain value of the 

transaction, taking into account foreign exchange rates, into 
the desired BIN. Transaction processing center 30 may mark-up 
or mark-down or otherwise access a fee on the monetary value of 
the transaction for any currency conversion described above 



-38- 



Knowles et al. 
670744.00005 

based on the system settings. Merchant 20 is expecting to 
receive the monetary value of the transaction as quoted in 
request currency 120 in the form of merchant funding currency 
128. As a result of the currency conversions by transaction 
5 processing center 30, if merchant 20 receives more than 

expected based on request currency 120, then merchant 20 
benefited from the currency conversions in the transaction. If 
merchant 20 receives less than expected based on request 
currency 120, then merchant 20 will have paid a fee from the 
10 transaction. The currency conversion process in FIGs. 6 and 7 

allows transaction processing center 30 to control the points 
where currency conversion is performed and how' and to whom fees 
are accessed for the currency conversions. 

[00087] Acquiring bank 24 and merchant 20 are no longer 
15 dependent on card association 34 for the clearing or settlement 

currency conversions. Instead, the conversion from transaction 
currency 122 to clearing currency 124 and the conversion from 
settlement currency 126 and merchant funding currency 128 can 
be managed and handled by transaction processing center 30 on 
20 behalf of merchant 20 and ' acquiring bank 24 and for the benefit 

of its partners. 

[00088] FIG. 7 illustrates the steps involved in the 
operation of currency conversion process. Step 140 receives 
the credit card transaction from merchant 20 in request 

25 currency 120 which is different from transaction currency 122. 

Step 142 converts request currency 120 to transaction currency 
122. Step 144 receives a credit .card transaction initiated by 
merchant 20 having a monetary value stated in transaction 
currency 122 as a baseline value. Step 146 converts 

30 transaction currency 122 to clearing currency 124 which is 

selectable to match the native currency of issuing bank 14. 
Step 148 forwards the credit card transaction to card 
association 34 and issuing bank 14 with the monetary value of 
the credit card transaction in clearing currency 124. Step 150 
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selects settlement currency 126 to be received from card 
association 34. Step 152 converts settlement currency 126 to 
merchant funding currency 128. 

[00089] An advantage of having the currency conversion 
5 process as shown in FIGs . 6 and 7 is maximum flexibility to 

configure transaction processing system 10 to operate in any 
manner as requested by acquiring bank 24, if transaction 
processing center 30 is working for the acquiring bank. The 
currency conversion can be performed by transaction processing 

10 center 30, as illustrated in transaction A, where transaction 

currency 122 in USD is converted to clearing currency 124 in 
GBP so that card association 34 received the transaction in the 
native currency of issuing bank 14. If acquiring bank 24 or 
merchant so chooses, the currency conversion can be left to 

15 card association 34 by leaving clearing currency 124 in USD. 

The same holds true for transaction B. On the settlement side 
of transaction B, the currency conversion from issuing bank 14 
to the native currency of acquiring bank 24 can be handled by 
transaction processing center 30 by making clearing currency 

20 124 and settlement currency 126 the same currency. Card 

association 34 would not perform any currency conversion. The 
currency conversion can be left to card association 34 by 
leaving settlement currency 124 the same as merchant funding 
currency 128. By selecting the' currency conversion points 120- 

25 128, transaction processing center 30 can control the currency 

conversion process for the entire transaction. 
[00090] To handle the large number and variety of 
transactions processing through transaction processing system 
10, transaction processing center 30 includes a scheduler and 

30 event processor 160 as shown in FIG . 8. Scheduler 160 works in 

combination with data processing 82 in FIG. 4 to provide 
efficient utilization of the resources of transaction 
processing center 30. Scheduler 160 is a computer program or 
operating system executing on a server or a distributed 
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computer system. The computer system running scheduler 160 
includes one or more CPUs, electronic memory, hard disk drive, 
and interfaces to communicate with peripherals. Scheduler 160 
uses database 162 residing on a hard disk drive. Database 162 
is configurable with timing, instructions, and other 
information used by servers 164, 166, and 168 which run data 
processing 82. Database 162 includes information such as 
process identifier, execution interval, polling interval, 
concurrency requirements, dependencies, and error checks. 
[00091] Scheduler 160 schedules various processes or client 
applications to run on servers 164-168 and keeps track of the 
individual runs or executions. Assume scheduler 160 is 
configured to run a clearing and settlement as a process every 
60 minutes. Database 162 would have an entry for a process 
identifier, say process number 200, for the clearing and 
settlement process. The time interval is 60 minutes, although 
the time interval can be any length of time. The polling 
interval is set to 10 minutes. The clearing and settlement 
process would typically not have any concurrency requirements 
because more than one clearing and settlement process could 
potentially run at one time. The clearing and settlement 
process may have dependencies that would be recorded in the 
entry for process number 200 in database 162. 

[00092] Server 164 is a computer system operating under the 
control of a CPU. Server 164 operates a computer program which 
is enabled or configured to run one or more predefined 
processes. When server 164 comes on-line, the software 
processes configured to run on server 164 each in turn query or 
check in with scheduler 160, identify the process (e.g. process 
number 200), and requests a task or assignment. A first 
process, running on server 164 will query or check in with 
scheduler 160 and request a task according to its 
configuration. If there is such a task to be performed, 
scheduler 160 provides execution instructions to the first 
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process. - If there are no such tasks for the first process, 
scheduler 160 gives the first process its next time to check 
in. A second process configured to run on. server 164 will 
check in with scheduler 160 and request a task according to its 
5 configuration. If there is such a task to be performed, 

scheduler 160 provides execution instructions to the second 
process. If there are no such tasks for the second process, 
scheduler 160 gives the second process its next time to check 
in . 

10 [00093] Assume scheduler 160 gives the first process 

configured to run on server 164 the task of running the 
clearing and settlement process and schedules the execution 
time in 60 minutes. Scheduler 160 also informs server 164 that 
there are no concurrency requirements or no dependencies and 

15 that it should poll or check back with scheduler 160 every 10 

minutes (poll interval) until execution time. The first 
process on server 164 keeps track of the time and polls 
scheduler 160 every 10 minutes to see if any instructions have 
changed. If the situation changes, such as a event on 

20 transaction processing center 30 or an update to database 162, 

then the first process on server 164 may receive revised 
instructions from scheduler 160 at one of the polling times. 
[00094] At the appointed execution time, the first process on 
server 164 queries or checks in with scheduler 160 one last 

25 time before executing process number 200. If all is good to 

go, server 164 begins executing process number 200. Server 164 
starts executing the clearing and settlement process by 
extracting one or more files from incoming queue 80 that have 
the file number associated with clearing and settlement. The 

30 file is parsed and the data is processed. During the execution 

of the clearing and settlement process, server 164 further 
records or logs in various information and events related to 
execution of the clearing and settlement process into database 
162. For example, server 164 records the start time, 
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completion time, and completion of various status check points 
during the execution of the clearing and settlement process 
into database 162. The status check points can be used for 
error correction and restart if the process does not complete 
5 successfully. When the clearing and settlement process is 

complete, then server 164 notifies scheduler 160 that the task 
is complete. Scheduler 160 then assigns server 164 its next 
task of another clearing and settlement process to be run in 
another 60 minutes with instructions to poll every 10 minutes. 

10 [00095] In another embodiment, server 164 may contain a 

number of processes. Server 164 will check in with scheduler 
160 and see want needs to be done and then activate the 
appropriate process. In addition' to clearing and settlement, 
if server 164 were enabled to handle generating certain 

15 reports, say process number 300, then scheduler 160 would be 

able to give server 164 either process number 200 or process 
.number 300 for its next assignment. Thus, when a process 
checks in for work, scheduler 160 will assign a task based on 
the abilities of the process and the priority of the work to be 

20 done. 

[00096] Scheduler 160 tracks and handles concurrency 
constraints. Some processes can run concurrently and others 
cannot. If a process is concurrency constrained, i.e. it must 
execute by itself and finish before another like or related 

25 process can start, then scheduler 160 will hold off such like 

or related processes until the concurrency constrained process 
finishes. For example, a first account reconciliation may be 
concurrency constrained so that a second account reconciliation 
cannot run until the first account reconciliation is finished. 

30 Scheduler 160 may allow certain processes to operate 

concurrently. For example/ first and second reports which are 
merely accessing data, possibly the same data, can be run 
simultaneously . 

[00097] Scheduler 160 can also track and handle dependency 
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constraints. Some processes may be required to wait until 
another process finishes. For example, the clearing and 
settlement process may have to wait until an audit is finished 
so the underlying data does not change during the audit. 
5 Alternately, an account reconciliation may have to wait for a 

clearing and settlement to run so that transaction processing 
center 30 has the latest data. 

[00098] At times a process might fail to complete. Scheduler 
160 waits to receive a report from server 164 that the assigned 

10 task was successfully completed. If there is a run problem, 

then server 164 will record and report the last known good 
check. point or event. Scheduler 160 analyzes what has been 
done and what still needs to be done so the failed process can 
be restarted at the last known good check point without 

15 repeating unnecessary and duplicative steps in the process that 

might lead to other errors . 

[00099] As the work load increases, scheduler 160 supports 

adding more process resources without the need to reconfigure 
transaction processing center 30. Server 166 is a computer 

20 system running a computer program under the control of a CPU. 

Server 168 is also a computer system running a computer program 
under the control of a CPU. Servers 164, 166, and 168 may be 
local or remote servers in a distributed system. Servers 164- 
168 are configured to run one or more processes on transaction 

25 processing center 30. Server 164 may be configured to execute 

a first type of process such as clearing and settlement. 
Server 166 may be configured to execute the first type of 
process and/or a second type of process such as a report. 
Server 168 may be configured to execute yet another type of 

30 process. 

[000100] Assume server 166 comes on-line with a configuration 
that handles process number 200 and process number 300. 
Further assume server 168 comes on-line with a configuration 
that handles only process number 300. Servers 166 and 168 
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communicate with scheduler 160. Scheduler 160 looks in 
database 162 to see what are the next priority processes for 
which servers 166 and 168 are configured to run. Tasks are 
assigned to processes on servers 166 and 168 accordingly with 
5 the associated execution time and polling interval. 

[000101] Assume that at time t 0 server 164 queries or checks 
in with scheduler 160 and is assigned process number 200 in 60 
minutes, e.g. 8pm. At time t 0 +5 minutes, server 166 queries or 
checks in with scheduler 160 and is assigned the next process 

10 number 200 at 9pm. At time to+10 minutes, server 168* queries or 

checks in with scheduler 160 and is assigned process number 
300. At 8pm, server 164 queries scheduler 160, receives final 
okay to run, executes the assigned process and completes at 
8:20pm. Server 164 checks in with scheduler 160 to let it know 

15 that the process number 200 at 8pm was successfully completed 

and that server 164 is ready for the next task. Scheduler 160 
has already assigned the 9pm time slot for clearing and 
settlement to server 166. However, there are a number of 
reports pending on transaction processing center 30. Scheduler 

20 160 assigns server 164 to execute a process number 300 to run 

at 8:30pm in order to get a few reports done since the clearing 
and settlement is in taken care of for time being. 
[000102] Since scheduler 160 hands out tasks as each server 
164-168 checks in, there is no need to reconfigure database 

25 162. When server 164' is operating by itself, it had 100% of 

the work load. When server 166 comes on-line, it shares the 
load equally with server 164. The configured processes on 
servers 164 and 166 have the same capability and, on the 
average, scheduler 160 will use each the same as they query for 

30 tasks. When server 168 comes on-line, it will share the load 

as well but may be not equally with servers 164 and 166 because 
server 168 can only do reports. Nonetheless, the processing 
capacity of transaction processing center 30 is scalable by 
adding new process resources and servers. Each new process 



-45- 



Knowles et al. 
670744 .00005 

shares the work load depending on the tasks to be preformed and 
the capabilities of the processes. Again, there is no need to 
reconfigure database 162 with each new process added to 
transaction processing center 30 because scheduler 160 uses the 
5 resources on hand and distributes the work according to its 

capability as each process checks in.. 

[000103] FIG. 9 illustrates the steps involved in the 
operation of scheduler 160. Step 170 provides servers 164, 
166, and 168 each having one or more configured processes. 

10 Step 172 initiates first query to scheduler 160 for an 

execution instruction. Step 174 initiates . second query to 
scheduler 160 prior to execution of the process to confirm the 
execution instruction. Step 176 executes the process after 
receiving confirmation of the execution instruction. Step 178 

15 configures server 164 to execute a first type of process. Step 

180 configures server 168 to execute a second type of process. 
[000104] Transaction processing system 10 handles a large 
number of individual transactions between merchants and 
customers. Accuracy in the transaction is an important aspect 

20 and consideration for both parties, as well as the financial 

institutions and third party service providers involved in 
processing the transactions. Merchant 20 wants to receive the 
correct amount of money. Cardholder 12 wants to be properly 
charged for the goods or services purchased. Acquiring bank 

25 24, issuing bank 14, card association 34, and transaction 

processing center 30 each have vested interests in accurate 
transactions for the reputation and integrity of the system and 
to ensure that each receives the proper fees. 

[000105] To maintain the accuracy of transaction processing 
30 system 10, transaction processing center 30 includes account 

reconciliation processor 200 as shown in FIG. 2. Account 
reconciliation processor 200 is implemented as application 
software or computer program (s) executing on local or 
distributed computer systems. Account reconciliation processor 



-46- 



Knowles et al. 
670744.00005 

200 is shown with a connection to data storage device 54 in 
order to access the data, records, and other information 
associated with the transactions. Transaction processing 
center 30 may access other sources of information from card 
association 34, acquiring bank 24, and issuing bank 14 for 
account reconciliation processor 200. 

[000106] The transaction usually begins with a purchase 
authorization request and concludes with clearing and 
settlement. In the purchase authorization requests and in the 
clearing and settlement transactions, transaction processing 
center 30 will have provided card association 34 the 
information needed to process and complete each credit card 
transaction. Such information includes identity of cardholder 
12, identity of merchant 20, amount of the purchase, date of 
transaction, clearing currency, and settlement currency. The 
cardholder information may include name, address, primary 
account number, PIN .number, fraud protection data, etc. 
[000107] After clearing and settlement, card association 34 
issues transaction statements as represented by block 202 of 
account reconciliation processor 200 in FIG. 10. The- card 
association generated transaction statement includes a summary 
of the funds to be paid as part of the clearing and settlement 
process for transactions occurring on the processing date or 
dates. Each card association may have unique format and 
content for their own statement. For example, Visa issues a 
VisaNet Settlement Service (VSS) Statement and MasterCard 
issues an xxx (INET) Statement. The transaction statement is 
compiled by card association 34 and will include, for each 
processing date, a summary or aggregation of the funding due to 
each acquiring bank and the funding due to each merchant 
associated with the respective acquiring bank. 
[000108] The association transaction statement breaks down 
the funding due into reporting categories such as (1) sale of 
goods and services, (2) credits, (3) interchange fees, (4) 
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charge-backs, and (5) representments. The amount of sale of 
goods and services is the amount of the purchase to be charged 
against cardholder 12 and ultimately paid to merchant 20. 
Credits are amounts credited back to cardholder 12 for a 
5 variety of reasons, e.g. return of goods, cancellation or 

rejection of services, and reimbursement to settle a dispute 
over the transaction. 

[000109] Interchange fees are service charges and other fees 
paid to financial institutions such as card association 34, 

10 acquiring bank 24, and issuing bank 14 for services provided. 

The interchange fee structure can be set according to any 
established or negotiated formula, including flat rates, 
percentage of sales, volume discounts, and sliding scales. The 
interchange fees may be dependent on the type of merchant and 

15 type of transaction. Large retail merchants generally have 

lower rates because of the high volume and low risk. Small 
merchants and telemarketing merchants have higher rates because 
of the higher risk or higher per transaction cost. The fees 
associated with any currency conversion may also be reflected 

20 in the interchange fee. The association transaction statement 

typically lists the exchange rates used to perform currency 
conversions, or includes a reference to exchange rates 
published by a financial institution, in order to understand 
how the fees and service charges associated with the 

25 transactions are calculated. Card association 34 may assess 

other fees for special services or processing, e.g. manual data 
entry of the credit card number as opposed to automated entry 
by swiping the card through a data entry terminal. 
[000110] Charge-backs are credits to cardholder 12 for 

30 erroneous and disputed charges. If cardholder 12 disputes the 

accuracy or authenticity of a transaction, card association 34 
immediately executes a charge-back to credit the carholder's 
account until the matter can be reviewed. For example, if upon 
reviewing his/her statement, cardholder 12 believes that a 
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particular transaction has not been authorized or has been 
authorized for a different amount or that the goods are not as 
promised or represented, then cardholder 12 contacts acquiring 
bank 24 or card association 34, and the disputed amount is 
5 taken off the cardholder's statement. The charge-back is 

charged against merchant 20. 

[000111] If merchant 20 maintains that the charge is 
legitimate, then merchant 20 makes a representment of the 
transaction, i.e. processes the transaction again through the 

10 system for payment, with accompanying documentation or other 

evidence of the authenticity of the transaction. Thus, whereas 
a charge-back will occur should cardholder 12 state that he/she 
did not purchase the goods, a representment will occur when 
merchant 20 produces a credit card charge slip signed by 

15 cardholder 12. Cardholder 12 may continue the challenge and 

compel a second charge-back by denying the authenticity of the 
signature, but at least the issues are rapidly focusing on a 
resolution or outcome to the issue. 

[000112] Card association transaction statement data in block 
20 202 represents the data and information published or provided 

by card association 34 describing each transaction and how and 
when the transaction will be funded. Card association 34 
provides such information to transaction processing center 30 
either in a printed or electronic format, and broken down by 
25 the processing date, merchant, cardholder, and reporting 

categories noted above. 

[000113] From the association transaction statement, for each 
processing date, transaction processing center 30 will know how 
card association 34 plans and expects to clear and settle the 
30 transactions for the respective date. The association 

transaction statement is not an actual funding event, i.e. 
where funds are transferred from one account to another, but 
rather a summary of the transactions that will be funded. The 
funding may occur the same day as the association transaction 
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statement, or the funding may occur day(s) later. The 
association transaction statement may show transactions on a 
Saturday, Sunday or holiday. However, since financial 
institutions are generally not open on weekends and holidays, 
the actual funding does not occur until the next regular 
business day. 

[000114] Transaction processing center 30 does not 
necessarily provide all information related to the transaction 
or the parties involved to card association 34. For example, 
transaction processing center 30 may not provide personal or 
financial information related to cardholder 12 or merchant 20 
or information concerning other accounts or other transactions 
that are not essential or relevant to the present transaction. 
Issuing bank 14 collects a large amount of personal and 
financial information about cardholder 12 in its application 
form before issuing a credit card. Acquiring bank 24 gathers a 
large amount of similar information about merchant 20 when 
opening one or more accounts. Transaction processing center 30 
maintains information concerning merchant 20 and cardholder 12 
from previous transactions. Much of this information is not 
relevant and is not sent to card association 34 or otherwise 
processed with each credit card transaction. 

[000115] Moreover, transaction processing center 30 does not 
provide prior currency conversion information for the present 
transaction to card association 34. Acquiring bank 24 or 
transaction processing center 30 may perform one or more 
currency conversions before forwarding the transaction to card 
association 34. Transaction processing center 30 typically 
does not provide any information about request currency 120 and 
transaction currency 122 to card association 34, either in 
terms of the denomination of the prior currency, the exchange 
rate utilized, and any fees imposed for the service. Also, 
card association 34 generally does not need to know about 
merchant funding currency 128. Card association 34 is provided 
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information concerning the currency in which it is receiving 
the transaction, i.e. clearing currency 124, and the currency 
in which it is expected to fund the transaction, i.e. 
settlement currency 126. 
5 [000116] From block 202, transaction processing center 30 

receives an association transaction statement, compiled and 
based on relevant information sent to card association 34, 
which summarizes the transactions to be funded according to the 
rules and procedures of the card association. In a separate 

10 and independent operation, transaction processing center 30. 

retrieves data from data storage device 54, and other sources 
of information from card association 34, acquiring bank 24, and 
issuing bank 14, and generates its own transaction statement as 
shown in block 204 of account reconciliation processor 200. 

15 The data retrieved from data storage device 54 and used to 

generate the transaction statement is the same or similar data 
that is sent to card association 34 during the purchase 
authorization request and clearing and settlement transactions. 
[000117] Transaction processing center 30 will have already 

20 assimilated and compiled the procedures, policies, rules, 

rates, and fees under which and by which card association 34 
operates to process and fund transactions. The process of 
gathering the procedures and rules of card association 34 
involves accessing and reviewing a variety of resources. Some 

25 procedural information is published or otherwise available from 

card association 34. Some information comes from academic, 
banking, and other financial institutions. And some 
information comes from review and analysis of the association 
transaction statement to understand how the statement is put 

30 together and how certain circumstances are handled. The set of 

rules used by transaction processing center 30 to generate its 
transaction statement are substantially the same as and 
consistent with the set of rules used by card association 34. 
[000118] The mechanics of formulating a transaction statement 
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involve adding the charges and representments, substracting the 
credits and charge-backs, and assessing the interchange fees 
and service charges at established and defined points of the 
transaction according to the rules and procedures of card 
5 association 34. The exchange rates are also determined and 

imposed by established and conventional set of rules of card 
association 34. Exchange rates are generally published by 
financial institutions at regular intervals. The process 
fu-rther includes a determination on which day a transaction 

10 should be processed, when exchange rates are updated, variances 

in fees structures, and how special circumstances such as data 
transmission errors or fraudulent credit card usage should be 
handled. For example, card association 34 has rules for cut- 
off times when a transaction should be processed on one day 

15 versus the next day. There exist rules as to when and under 

what circumstances exchange rates are updated. The exchange 
rate may be updated at designated times during the day or may 
be updated at significant changes in the financial markets. 
Fee structures can be flat rates, percentage of sales, volume 

20 discounts, sliding scales, or other negotiated formula. With 

the high volume of credit card transactions, the vast majority 
of transactions fall in the routine category of calculations 
described above and even the small remainder of the non-routine 
transactions have generally been seen before and there exist 

25 precedence for proper and accepted disposition. 

[000119] With apriori knowledge of the procedures, policies, 
rules, rates, and fees of card association 34, and using the 
same or similar data which has been sent to card association 
34, but without reference to the association transaction 

30 statement, transaction processing center 30 generates its own 

transaction statement (''simulated transaction statement") for 
given processing date or dates. In other words, the 
transaction statement created by transaction processing center 
30 is an independent simulation or baseline or comparison 
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statement which is generated using substantially the same and 
consistent procedures, rules and data that card association 34 
used in creating its transaction statement. By using a set of 
rules which have been compiled from and which are consistent 
with the set of rules used by card association 34, the 
simulated transaction statement is an accurate simulation of 
the association transaction statement and will generate similar 
results given similar data input. If there is a discrepancy 
between the association transaction statement and the simulated 
transaction statement, then that discrepancy is likely an error 
in one statement or the other and warrants investigation to 
find the root cause of the problem. 

[000120] The simulated transaction statement generated by 
transaction processing center 30 is created for the purpose of 
and in a format that lends itself to comparison to the 
association transaction statement from card association 34. 
The association transaction statement may be received in a 
tabulated printed format, or it may be received in electronic 
form with values identified for each line item and subtotal. 
The simulated transaction statement is generated with a similar 
format to provide ready comparison to the association 
transaction statement and efficient evaluation of any 
discrepancy. The simulated transaction statement may be 
generated as a table of values. stored in the computer system 
correlated to the line items and subtotals of the association 
transaction statement. If desired, the simulated transaction 
statement can be printed in tabular format for human review ■ 
from the electronic table of values. 

[000121] Since the simulated transaction statement is 
generated from the data stored in data storage device 54, which 
contains data on a per transaction basis, the simulated 
transaction statement can provide more information for the user 
than has been provided in the transaction statement from card 
association 34 . In addition to the summary or aggregation of 
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transactions such as found in the association transaction 
statement, the simulated transaction statement from transaction 
processing center 30 can be formatted to show each individual 
transaction and all associated data that when into the summary 
or aggregation of transactions. In other words, the simulated 
transaction statement provided the user with the ability to 
drill down into the statement with maximum resolution available 
from the data in data storage device 54 and other information 
sources available to transaction processing center 30 from card 
association 34, acquiring bank 24, and issuing bank 14 to 
assist in identifying discrepancies and isolating the root 
problem. 

[000122] Block 204 is capable of importing present and prior 
monetary conversion rates from block 206. Block 206 is an 
electronic link to financial institutions to access monetary 
conversion rates that are used to determine in part the 
interchange fees. The association transaction statement may be 
set up to use exchange rates posted by financial institutions 
at given days and times. Block 204 may need to access those 
records to determine which exchange rate was utilized by card 
association 34 for the transaction. 

[000123] In block 208," transaction processing center 30 
performs account reconciliation of the association transaction 
statement from card association 34 by comparing the association 
transaction statement to the simulated transaction statement 
for. the same processing date or dates. The comparison is done 
by a computer program which compares values from the simulated 
transaction statement to corresponding values from the 
association transaction statement and identifies any variance 
or discrepancy between the statements. The account 
reconciliation could begin by comparing only the final totals. 
However, theoretically two identical offsetting errors in the 
subtotals could make the final total correct, but the statement 
would still contain errors. With the available computing power 
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simulated transaction statement on a given date. A comparison 
of the association transaction statement and simulated 
transaction statement for adjacent dates is made to see if 
another date is off by the same amount. If the previous day 
5 shows the funding amount to be paid to the merchant is $100 

more on the association transaction statement as compared to 
the simulated transaction statement on that date, then the 
error is likely a wrong processing date one way or the other. 
Similar checks can be made for same day of the month for 

10 adjacent months and for same day and month for adjacent years. 

[000126] The same process applies to comparisons between 
different merchants on the same or adjacent dates. If the 
comparison between the association transaction statement and 
simulated transaction statement shows one merchant long by the 

15 same amount that another merchant is short, or if there is 

otherwise a difference between multiple merchants, then the 
error may be in misidentif ication of one or more merchants. On 
the other hand, if the comparison between the association 
transaction statement and simulated transaction statement shows 

20 one reporting category long by the same amount that another 

reporting category is short, or if there is otherwise a 
difference between multiple reporting categories, then the 
error may be in misclassif ication of one or more transactions. 
[000127] Another indicator can be that the discrepancy or 

25 difference between the association transaction statement and 

simulated transaction statement is a small percentage of the 
total but otherwise has no correlation with any other line item 
or individual value. In this case, the discrepancy may be with 
the exchange rate as a percentage of the transaction value. 

30 Block 210 is capable of reviewing and confirming the exchange 

rates used with the association transaction statement and ■ 
simulated transaction statement. 

[000128] Yet another indicator can be that the interchange 
fees deviate from the known formula or otherwise differ from 
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historical calculations. If a flat rate has historically been 
used and a different fee shows-up, or if the service charges do 
not add up as expected, then the formulation or determination 
of the interchange fee may be in error. Block 210 reports back 
5 the possible or likely origin of the discrepancy of the account 

reconciliation . 

[000129] Moreover, since the simulated transaction statement 
is generated from and has access to the per transaction data 
stored in data storage device 54, as well as access to other 

10 sources of information from card association 34, acquiring bank 

24, and issuing bank 14, the simulated transaction statement 
can be dynamically re-formatted to show further detail of 
individual transactions, particular aspects of the transaction, 
and other associated information. The per transaction 

15 resolution available to transaction processing center 30 and 

utilized in account reconciliation processor 200 allows the 
user to view the data in a variety of ways. For example, if a 
subtotal for a merchant is in discrepancy, then the simulated 
transaction statement can be re-formatted to show further 

20 detail for each any one of the transactions under that 

subtotal. Alternatively, if the user needs to drill down into 
one particular aspect of the transaction, or needs to make 
comparisons to other transactions, then that information is 
readily available from the per transaction database. 

25 [000130] Transaction processing center 30 has the advantage 

of making use of other merchant and cardholder data, which has 
not been sent to card association 34, but is available to 
resolve discrepancies between the association transaction 
statement and simulated transaction statement. Even though 

30 some data may not have been relevant or applicable to the 

transaction at the time and therefore not sent as part of the 
transaction and has not been used to generate either the 
association transaction statement or the simulated transaction 
statement, such data may be used by block 210 to answer or 
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yield clues as to why and where the discrepancy exists. For 
example, merchant 20 may have multiple accounts with acquiring 
bank 24. A transaction may be incorrectly processed to an 
alternate account of merchant 20. The existence and 
identification of all merchant accounts is not relevant any 
particular transaction and therefore not given to card 
association 34. Transaction processing center 30 can readily 
review the association transaction statement and simulated 
transaction statement for the other account (s) of merchant 12 
to identify the source of discrepancy. Cardholder 12 may have 
an alias name or may have had a name change, e.g. recently 
married, or some other identification issue, which could be the 
cause of the error and not necessarily available to card 
association 34. Cardholder 12 may have used credit cards with 
more than one card association to make a single purchase, e.g. 
part on Visa and part on MasterCard, in which case the 
offsetting errors may exist on different card association 
transaction statements. Without the complete merchant and 
cardholder profiles, the association transaction statement 
itself would not be able to identify the origin of some errors, 
even if the existence of an error was known. However, with 
such expanded information, transaction processing center 30 can 
make additional checks not available to any one card 
association 34 to track down the error. In fact, transaction 
processing center 30 or similarly situated institution may be 
the only entity with access to sufficient information necessary 
to efficiently identify the source (s) of the problem. 
[000131] Block 210 processes through the table of common or 
known errors and indicators, compares individual values between 
association the transaction statement and simulated transaction 
statement, and determines likely origin (s) of the discrepancy. 
The corrective action of block 210 includes both correction of 
the immediate error and further consideration of changes in 
existing procedures or additional training to prevent the error 
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from reoccurring in other transaction statements. The 
discrepancy could have been caused by a software bug, data 
entry error, clerical error, or a change to the card 
association processing procedures and set of rules that had not 
5 yet been reflected in the set of rules and process used to 

generate the simulated transaction statement. Once the error 
or discrepancy is identified, block 210 can make 
recommendations and decisions can be made as to how- to most 
efficiently implement the corrective action. 

10 [000132] The corrective action will dependent to a large 

extent on the nature of discrepancy, practicality of various 
solutions, and effort and politics involved in implementing 
change. The corrective action may involve a software fix to 
change the way the statements are generated. The corrective 

15 action may involve a procedural change, clarification or 

further training as to how data in entered or processed. The 
corrective action may involve a fundamental change to the 
established rules and procedures of card association 34 if a 
major new issue is uncovered and brought to the table. The 

20 corrective action may involve solving quality problems or 

terminating the use of one or more third party service 
providers which make an unacceptable number of administrative 
or processing errors. 

[000133] Corrective action is important because as bad as one 
25 error can be, it is even worse to make the same error again. 

The cost of any error becomes amplified when it is not 
corrected to prevent reoccurrence. Transaction processing 
center 30 has the ability to identify errors, isolate their 
origin, take corrective action, and generally work the bugs out 
30 of the system. In a mature system, the account reconciliation 

process in block 208 should rarely, if ever, find 
discrepancies. But knowing that the check and balance is in 
place instills stability, confidence, and credibility in the 
system. Everyone get what is fair and expected and an 
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acceptable level of customer service. 

[000134] As noted above, the accuracy and integrity of the 
transaction statement is important. Mistakes and errors cost 
time and money, adversely effect reputation, and generally are 
5 unacceptable to the all parties concerned. Ideally, processing 

credit card transactions involves application of arithmetic to 
given values under predetermined procedures and rules. People 
have little if any patience for administrative, clerical, and 
processing errors in routine monetary transactions, be they 
10 large or be they small. There is a significant benefit in 

finding and correcting errors in the system. Accuracy remains 
a paramount consideration and concern to maintaining the 
integrity of the system. 

[000135] In addition to the association transaction 

15 statements, transaction processing center 30 receives a funding 

statement in block 212. The funding statement may come from a 
financial institution, such as the bank servicing the accounts 
of transaction processing center 30, or the statement may come 
directly from card association 34. The bank funding statement 

20 may have a format unique to the institution which generated the 

statement, or it make have a format similar to the association 
transaction statement. Whereas the association transaction 
statement identifies transactions which are cleared and settled 
on a given date, but yet to be funded, the bank funding 

25 statement shows funds that have actually changed hands, i.e. 

card association 34 has transferred funds to an account held by 
transaction processing center 30. A particular transaction may 
be included in an association transaction statement on a given 
business day and further included in a bank funding statement 

30 on the same day. However, a transaction which occurs on a 

weekend or holiday will likely be included in an association 
transaction statement on a day different from the bank funding 
statement. Association transaction statements are issued most 
every day of the year. Bank funding statements are typically 
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assimilated and compiled the procedures, policies, rules, 
rates, and fees under which and by which merchant 20 and card 
association 34 operates to process transactions. The process 
of gathering the procedures and rules of card association 34 
5 involves accessing and reviewing a variety of resources. Some 

procedural information is published or otherwise available from 
card association 34. Some information comes from academic, 
banking, and other financial institutions. And some 
information comes from review and analysis of the bank funding 

10 statement to understand how the statement is put together and 

how certain circumstances are handled. The set of rules used 
by transaction processing center 30 to generate its funding 
statement are substantially the same as and consistent with the 
set of rules used by card association 34 to determine what the 

15 funded amount should be. The institution generating the bank 

funding statement uses a more simplified procedure, i.e. it 
merely transfers certain amounts of money to transaction 
processing center 30 in accordance with instructions and 
authorization from card association 34, without knowledge of 

20 the underlying transactions. 

[000139] With apriori knowledge of the procedures, policies, 
rules, rates, and fees of card association 34, and using the 
same or similar data which has been sent to card association 
34, but without reference to the bank funding statement, 

25 transaction processing center 30 generates its own funding 

statement ("simulated funding statement") for given processing 
date or dates. In other words, the simulated funding statement 
created by transaction processing center 30 is an independent 
simulation or baseline or comparison statement which is 

30 generated using substantially the same and consistent 

procedures, rules and data used by card association 34 in 
determining what the funded amount should be for a given day; 
the funded amount that ultimately shows up in the bank funding 
statement. By using a set of rules which have been compiled 
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from and which are consistent with the set of rules used by the 
card association to determine what the funded amount should be 
for a given day, the simulated funding statement is an accurate 
simulation of the bank funding statement and will generate 
similar results given similar data input. If there is a 
discrepancy between the bank funding statement and the 
simulated funding statement, then that discrepancy is likely an 
error in one statement or the other and warrants investigation 
to find the root cause of the problem. 

[000140] The simulated funding statement generated by 
transaction processing center 30 is created for the purpose of 
and in a format that lends itself to comparison to the bank 
funding statement. The bank funding statement may be received 
in a tabulated printed format, or it may be received in 
electronic form with values identified for each line item and 
subtotal. The simulated funding statement is generated with a 
similar format to provide ready comparison to the bank funding 
statement and efficient evaluation of any discrepancy. The 
simulated funding statement may be generated as a table of 
values stored in the computer system correlated to the line 
items and subtotals of the bank funding statement. If desired, 
the simulated funding statement can be printed in tabular 
format for human review from the electronic table of values. 
[000141] Block 214 is capable of importing present and prior 
monetary conversion rates from block 206. The monetary 
conversion rates are used to determine in part the interchange 
fees. The bank funding statement may be set up to use exchange 
rates posted by financial institutions at given days and times. 
Block 204 may need to access those records to determine which 
exchange rate was utilized by card association 34 for the 
transaction . 

[000142] In block 216, transaction processing center 30 
performs account reconciliation by comparing the bank funding 
statement to the simulated funding statement for the same 
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processing date or dates. The comparison is done by a computer 
program which compares the simulated funding statement to the 
bank funding statement value by value and identifies any 
variance or discrepancy between the statements. 
5 [000143] Ideally, if transaction processing center 30 

generates a simulated funding statement using substantially the 
same and consistent procedures, rules, and data as the card 
association in determining what the funded amount should be for 
a given day, then the simulated funding statement should match 
10 and agree with the bank funding statement. An agreement 

between the bank funding statement and simulated funding 
statement provides the parties with assurances that there are 
no errors in the transaction processing system. 

[000144] If a discrepancy is found, then block 218 identifies 
15 the discrepancy and takes corrective action. The 

identification of the discrepancy may involve a number of steps 
and approaches. Block 218 can operate in an automated fashion, 
i.e. by using a computer program to examine possible causes and 
origins of the discrepancy. Block 218 can operate in a manual 
20 fashion, i.e. with a person reviewing the bank funding and 

simulated funding statements, to identify the discrepancy. 
Block 218 includes a list or table of common errors and 
indicators of such errors. Upon determination that a 
discrepancy exists, block 218 goes through the list of common 
25 or possible errors and indicators to find the problem in a 

similar manner as described for block 210. 

[000145] Since the simulated funding statement is generated 
from and has access to the per transaction data stored in data 
storage device 54, as well as access to other sources of 
30 information from card association 34, acquiring bank 24, and 

issuing bank 14, the simulated funding statement can be 
dynamically re-formatted to show further detail of individual 
transactions, particular aspects of the transaction, and other 
associated information. The per transaction resolution 
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available to transaction processing center 30 and utilized in 
account reconciliation processor 200 allows the user to view 
the data in a variety of ways. For example, if the user needs 
to drill down into a particular aspect of the transaction, or 
needs to make comparisons to other transactions, then that 
information is readily available from the per transaction 
database stored in data storage device 54. 

[000146] Block 218 processes through the table of common or 
known errors and indicators, compares individual values between 
the bank funding statement and simulated funding statement, and 
determines likely origin (s) of the discrepancy. The corrective 
action of block 218 includes both correction of the immediate 
error and further consideration of changes in existing 
procedures or additional training to prevent the error from 
reoccurring in other funding statements. The discrepancy could 
have been caused by a software bug, data entry error, clerical 
error, or a change to the card association processing 
procedures. Once the error or discrepancy is identified, block 
218 can make recommendations and decisions can be made as to 
how to most efficiently implement the corrective action in a 
similar manner as described for block 210. 
[000147] FIG. 11 illustrates the steps involved in the 
operation of account reconciliation processor 200. Step 220 
receives a first statement of financial transactions generated 
according to a first set of rules. Step 222 provides a second 
statement using a second set of rules consistent with the first 
set of rules used to generate the first statement. The second 
set of rules is compiled from the first set of rules such that 
the second statement simulates the first statement and 
generates similar results given similar data input. The second 
statement can be generated or re-formatted on a per transaction 
basis. Step 224 compares the second statement to the first 
statement to identify discrepancy between the first statement 
and the second statement. A first value from the first 
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statement is compared with a second value from the second 
statement to determine a difference between the first value and 
the second value. Step 226 identifies causation of the 
discrepancy between the first statement and the second 
statement by evaluating a list of possible errors. Step 228 
institutes correction action upon identifying discrepancy 
between the first statement and the second statement. 
[000148] Although the present invention has been described 
with respect to preferred embodiments, any person skilled in 
the art will recognize that changes can be made in form and 
detail, and equivalents may be substituted for elements of the 
invention without departing from the spirit and scope of the 
invention. Many modifications may be made to adapt to a 
particular situation or material to the teaching of the 
invention without departing from the essential scope of the 
invention. Therefore, it is intended that the invention not be 
limited to the particular embodiments disclosed for carrying 
out this invention, but that the invention will include all 
embodiments falling within the scope of the appended claims. 
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